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(57) Abstract: The present 
invention describes a gateway in 
an Open Service Access (OSA) 
network where Service Level 
Agreement (LSA) checks are 
performed by a Framework (15) 
on a Centra] Gateway node (1). 
A distinction is made between 
applications (10) that can be trusted, 
like applications provided by the 
same firm as the gateway, and other 
applications (12) that are not trusted 
for security reasons. Access request 
coming from the applications 
for accessinjg Service Capability 
Servers (SCSs) (4, 5) are checked by 
the framewoiic ( 15). Now the trusted 
applications (10) can get direct 
access to the Service Capability 
Servers (4, 5), but the untrusted 
applications (12) are only allowed 
to access so-called proxy SCSs (9) 
on the Central Gateway node (1). . 
The proxy SCSs (9) have the same 
interface as the SCSs (4, 5) running 
on the distant nodes (2, 3), and are 
downloaded by the Framework (15) 
from the distant SCS nodes (2, 3) 
to the Central Gateway node (1) 
during an initialization phase. 
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A secure Gateway with proxy Service Capability Servers for 
Service Level Agreement checking 

5 Field of the mvention 

The present invention relates to Open Service Access (OSA) for the implementation of 
a third generation wireless phone system called Universal Mobile Telecommmiications 
System (UMTS). The invention particularly relates to seciiring access to Service 
10 Capability Servers (SCSs). 

Prior Art 

Due to tlie 3^*^ generation network structure, applications within the UMTS Service 
1 5 Network can make use of core network functionality by means of open Application 
Program Interfaces (APIs). The open APIs, originally specified by the Parlay Group, 
are standardised within the 3rd Generation Partnership Project (3GPP) CN5 working 
group and the ETSI SPAN 12 group. 

In the OSA architecture, the logical entities that implement the open APIs are called 
20 Service CapabiUty Servers (SCSs). Additionally injfrastnicture APIs are specified called 
the Framework. Among other things, the Framework provides an API for registering an 
SCS, see Technical Specification Group Core Network, Open Service Access, 
Application Programrning Interface, Part 3 : Framework (Release 4), 3GPP Techn. 
Spec. 29.198-3 V4.1.0 (2001-06). See also ETSI ES 201 915-3 VO.0.4 (2001-06) Open 
25 Service Access; Application Programming hiterface; Part 3: Framework, - 

Several ways of implementing the APIs in a network are thinkable. One way is to 
provide all API implementations v^thin one physical network node (i.e., both the OSA 
Framework and SCS in the same node having protocols/interfaces to the various core 
30 network entities). This could be called a physical or single OSA gateway. A second 
way is a distributed approach. In this case, one node comprises central infrastructmre 
software (Framework) and maybe a few SCS components, but the rest of the SCSs run 
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on different nodes. Now, the OSA gateway is a logical gateway and API 
implementations can run on distributed nodes (i.e., SCSs). This means that the different 
entities provide their own APIs. This approach could be caUed logical or distributed 
OSA gateway. 

5 

Security in OSA is very important because appUcations can also be provided by other 
business domains than the network operator who provides the network capabilities. In 
practice, it might be that the network operator puts restrictions on the functionality of a 
certain SCS to be used by an application. What is allowed or not allowed, is defined by 
10 so-caUed Service Level Agreements (SLAs). A Service Level Agreement may consist 
of an off-line (e.g. by physically exchanging documents) and an on-line part. An 
application has to sign the on-line part of a service agreement before it is allowed to 
access any network service capability feature. 

15 The physical or single node gateway ^proach has disadvantages from a performance 
point of view as all the communication has to go via the OSA gateway node. The 
distributed ^roach has disadvantages from a security point of view because 
applications need to get direct access to the network nodes. A big advantage of the 
latter approach is that no implementation of the SCS software at the central gateway 

20 node is necessary for introducing new SCSs. In case of a true physical gateway 
solution, of course for each new SCS new software has to be implemented on the 
gateway. 

Summary of the invention 

25 

The problem to be solved by the present invention is to provide a system and method 
that overcome the disadvantages of the prior art approaches. 

The present invraxtion relate to a gateway node for implementing a gateway in an open 
service access network between one or more ^plications and one or more external 
30 service capability servers on service capability server nod^, comprising a framework, 
characterised in that said framework performs security checks on requests from 
applications to get access to one or more of the external service ciqpability servers using 
service level agreements, stored in a database. 
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In the present invention the physical and logical gateway approach are combined to 
benefit firom both prior art approaches. 

Furthermore, the present invention relates to a gateway node as described above, 
5 wherem said framework classifies the applications in trusted and untrusted applications. 

Moreover, the present invention relates to a gateway node as described above, wherein 
said Framework allows a trusted application direct access to said service capability 
servers but allows a untrusted application only access to proxy service capability 
10 servers running on die gateway node. 

Also, the present invention relates to a gateway node as described above, wherein said 
framework initiates downloading of application program interface fimctionality fi-om 
said service capability servers to said gateway node forming said proxy service 
15 capability servers. 

Furthermore, the present invention relates to a method for implementing a gateway 
node as described above, comprising the steps of: 

(a) receiving a request from an application to access a 

20 service capability server external to said gateway node, 

characterised in that the method also comprises the steps of: 

(b) downloading of appUcation program interface functionality from said 
service capability servers to the gateway node forming a proxy service 
capability servers; 

25 (c) classifying the application into either a trusted or an untrusted application; 

(d) requesting said external service capability server to create an object 
instance implementing required application program interface fimctionality; 

(e) sending a reference to said object instance to said application if it is a 
trusted application; 

30 (f) sending a reference to said proxy SCS to said application if it is an 

untrusted application; 
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(g) operating said proxy service capability servers to enable controlled 
coinraunications between said imtrusted application and said service 
capability server. 

5 In the present invention on the fly software can be provided to a node in the network 
that can deal with the checking of the Service Level Agreement. This keeps the actual 
SCS jfrom doing these checks ad therefore trusted applications are not bothered with the 
SLA checking overhead. Meanwhile untrusted j^plicationus do not have direct access to 
the actual SCSs and have to go through one specific node, which is beneficial firona a 
1 0 security point of view. 

Brief description of the drawings 

Below, the invention will be explained with reference to some drawings, which are 
15 intended for illustration purposes only and not to limit the scope of protection as 
defined in the accompanying claims. 

Fig. 1 shows a network system with a logical OSA Gateway with Proxy SCSs. 
Fig. 2 shows a possible arrangement for a network node. 
Fig. 3 shows a part of a network with two OSA Gateways. 

20 

Description of preferred embodiments 

In figure 1, an example of a network system v^th a logical (distributed) OSA Gateway 
is shown. The logical OSA Gateway shown, contains a Central Gateway node 1, and 
25 two SCS nodes 2, 3. In Figure 1 the physical nodes are depicted with dashed lines. On 
each of the SCS nodes 2, 3 one or more extraaai SCSs 4, 5 are running. An internal 
SCS 6 may be present on the Central Gateway node 1 itself 

One of the main drivers behind OSA is opening of the networks also for parties outside 
the domain of the network operator (owning the SCSs and the rest of the core network). 
30 Applications provided within the same domain as the network operator are usually 
addressed as trusted applications, while applications provided by ent^prises of a 
different domain (so-called 3rd parties) are usually addressed to as imtrusted 
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appUcations. That is why in figure 1 a distinction is made between trusted applications 
10 and imtrusted applications 12. The ^plications 10, 12 are depicted as elipses. 
On Central Gateway node 1, a Framework 15 is able to communicate with the 
applications 10, 12 through Framework to AppUcation (FtA) Interface 16. On the other 
5 hand, Framework 15 is communicating with the SCSs 4, 5, 6 through Framework to 
Service (FtS) Interface 17. One of the functions of the FtS Interface 17 is to register all 
the SCSs 4, 5, 6, so that they can be discovered by the applicatioie 10, 12, using the 
FtA Interface 16. 

10 In the present invention, the FtS-Interface 17 is extended by proxy initiaHsation 
software to make it possible to download one or more Proxy SCSs 9 firom all the 
external SCSs 4, 5, to the Central Gateway node 1. - 

The Framework 15 has access to a database with Service Level Agreement information, 
referred to as SLA database 28.1n figure 1, the SLA database 28 is situated in the 

1 5 Framework 15. However it should be understood that the SLA database 28 can also be 
situated outside flie Framework 15, and can even be situated on another network node. 
Everytime an application 10, 12 is requesting access to one of the external SCSs 4, 5, 
Framework 1 5 will look in the SLA database 28 for SLA information. If the trusted 
applications 10 want to access the external SCSs 4, 5, they first have to request the 

20 Framework 1 5 for a reference to the extemal SCSs 4, 5 see arrow 20. Then the 

Framework 1 5 checks to which extent the trusted applications 10 are allowed to use 
these extemal SCSs 4, 5, using the information in the SLA database 28. If access is 
allowed, the Framework 15 requests the SCSs 4, 5 to create an object instance, 
implementing the requested APIs, on Ihe SCS nodes 2, 3. Next, the Framework 15 

25 returns references to these objects to flie trusted applications 10, see arrow 21. The 
trusted appUcations 10 can then access the SCSs 4, 5 on SCS nodes 2, 3 directly, see 
arrow 22. 

If untrusted applications 12 want to access the SCSs 4, 5, they also have to request the 
Framework 15 for a reference to the different SCSs, see arrow 24. The Framework 15 
30 also checks to which extent the untrusted applications 12 are allowed to use these SCSs 
4, 5, using the information in the SLA database 28. In reply to that, the Framework 15 
creates SCS proxies 9 for the different SCSs 4, 5 on the Central gateway node 1. Then, 
as in the case of the trusted applicatioUi the Framework 15 requests the extemal SCSs 
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4, 5 to create an object instance implementing the requested APIs, on the SCS nodes 2, 
3. Next the Framework 15 returns references to the Proxy SCSs 9 to the untrasted 
applications 12, see arrow 25. In this way, the untrusted applications 12 only have 
access to the Proxy SCS 9, see arrow 26, and the Proxy SCS 9 only invoke the 
5 implementations at the distant SCS nodes 2, 3 in case the untrusted applications 12 are 
allowed the invokatipn according to the SLA, see arrow 27. This means that all 
tmtrasted ^plications 12 are handled by the (Firewall of tfie) Central gateway node 1 
and do not communicate directly with the SCS nodes 2, 3. This is beneficial from a 
security point of view, 

10 There are multiple ways on how to provide the Proxy SCSs 9 at the Central gateway 
node 1. One solution is that each time a Service instance for a particular application 
needs to be initiated, the Framework 15 contacts the distant SCSs 4, 5 by invoking a 
method (for example the getServiceManagerQ on the IpSvcFactory interface, see 3 GPP 
Technical Specification 29*198) with an indication that a Proxy SCS 9 is needed at the 

1 5 central Gateway node 1 . The SCSs 4, 5 then initiate the proxy Service software with the 
correct SLA checks and return this to the Framework 15 together with a reference to 
the Service instance that is created locally on the SCS node 2, 3. The reference to the 
Service instance will link the Proxy SCS 9 at the Central Gateway node 1 to the Service 
instance at the SCS node 2, 3. 

20 Another solution is that during installation time the SCSs 4, 5 registCT a Proxy SCS 9 at 
the central Gateway node 1, Each time a Service instance is needed, the Framework 15 
first contacts the Proxy SCS 9 by caUing e.g. the getServiceManagerQ method on the 
IPSvcFactoiy, see 3GPP Technical Specification 29.198. The Proxy SCS 9 then 
contacts the distant SCS 4, 5 and makes sure the correct Service proxy at the Central 

25 gateway node 1 and Service instance at the SCS node 2, 3 is started. In a preferred 
embodiment, the new operation for registering a Proxy SCS 9 in the FtS Interface 17, 
could be named registerProxyQ and is may be part of the IpFwServiceRegistration API, 
see 3GPP Technical Specification 29.198. A reference between the Proxy SCS 9 and 
the distant SCS 4, 5 is established by extending the current operation 

30 getServiceManagerQ on an interface, called the Service Factory API, with a parameter 
specifying a reference to the Proxy SCS 9. The downloading of the proxy SCS code is 
achieved by means of e.g, Java object seriaUsatioiL It is basically the same mecliardsm 
as downloading an applet in a client webbrowser. 



wo 03/017619 PCT/NLOl/00614 



Figure 2 shows a schematic hlock diagram of possible arrangement for a network node, 
like the Central Gateway node 1 and the SCS nodes 2, 3, comprising processor means 
41 with peripherals. The processor means 41 is coimected to memory units 38, 42, 43, 
5 44 which store instructions and data, one or more reading units 45 (to read, e.g., floppy 
disks 39, CD ROM's 40, DVD's, etc.), a keyboard 46 and a mouse 47 as input devices, 
aad as output devices, a monitor 48 and a printer 49* For data-communication to other 
nodes, an interface card 50 is provided that is connected to a network 51. Other input 
devices, like a trackball and a touch screen, and output devices may be provided for. 

10 The memory units shown comprise RAM 42, (E)EPROM 43, ROM 44 and hard disk 
38. However, it should be understood that there may be provided more and/or other 
memory imits known to persons skilled in the art. Moreover, one or more of them may 
be physically located remote from the processor means 41, if required. The processor 
means 41 are shown as one box, however, they may comprise several processing units 

1 5 functioning in parallel or controlled by one main processor, that may be located remote 
from one another, as is known to persons skilled in the art. 

It is observed that both trusted and imtrusted applications 10, 12 may run on a similar 
arrangement as shown in Figure 2, including its alternatives as indicated above. Instead- 
of physical I/O means 50, means for wireless communications (transmitters, receivers, 

20 transceivers) may be provided for. Applications 10, 12 may run on mainframes, PC*s, 
handheld computers, laptops, and mobile devices like mobile phones. 
Figure 3 shows an embodiment of the present invention with two OSA Gateways. In 
figure 3 two Central Gateway nodes 1, 81 are shown. Both Gateway nodes 1,81 can be 
accessed by trusted and untrusted apphcations at Application Servers of which only 

25 two untrusted apphcations 12, 82 are shown. One of the logical OSA Gateways 

comprises Central Gateway node 1 and SCS node 2. A second logical OSA.Gateway 
conqprises Central Gateway node 8 1 and SCS node 2. 

In the situation of figure 3, two untrusted supplications 12, 82 request access to an 
external SCS 4 running on a SCS node 2, via two separate Central gateway nodes 1, 81. 
30 Each Central Gateway node 1, 81 comprises a Framework 15, 85. The untrusted 

apphcations 12, 82 request the Frameworks 15, 85 for a reference to the external SCS 
4. Now, Framework 15 will create a Proxy SCS 9 on the Central Gateway node 1, and 
Framework 85 will create a Proxy SCS 89 on the Central Gateway node 8 1 . 
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Because in this example^ both applications are untrusted, the Frameworks 15, 85 
returns references to the Proxy SCSs 9, 89 to the imtrusted applications 12, 82. The 
untrusted applications 12, 82 then only have access to the proxy SCSs 9, 89, see arrow 
26 and 86 respectively. The Proxy SCSs 9, 89 will invoke implementations on the 
5 extemal SCS 4 (see arrows 27, 87) in accordance with SLAs stored at the 
corresponding Frameworks 15, 85, 

In this case both applications are untrusted applications. It should be understood that 
several combinations of trusted and untrusted applications are possible, and that this 
example can be expanded by adding more applications and/or gateways and/or SCSs. 

10 

In the embodiments described above, the word "gateway" is used to describe a 
collection of APIs, which gives applications access to the core (telecom) network. In 
the embodiments a gateway comprises a Framework and one or more SCSs. However 
other configurations may be possible such as a gateway only comprising a Framework. 
15 It shoxdd be understood that the definition of gateway as used in the embodiment does 
not limit the scope of the present invention. 
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API Application Program Interface 

OS A Open Service Access/Architecture 

5 SCS Service Capability Server 

SLA Service Level Agreement 

UMTS Universal Mobile Telecommimications System 
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Claims 

1. A gateway node (1) for implementing a gateway in an open service access 
network between one or more applications (10, 12; 82) and one or more external 

5 service capability servers (4, 5) on service capability server nodes (2, 3), comprising a 
framework (15), 

characterised in that said framework (15) performs security checks on requests from 
applications (10, 12) to get access to one or more of the external service capability 
servers (4, 5) using service level agreements, stored in a database (28). 

10 

2. A gateway node (1) according to claim 1, wherein said framework (15) classifies 
the applications (10, 12) in trusted and xmtrusted applications. 

3. A gateway node (1) according to claim 2, wherein said Framework (1 5) allows a 
15 trusted application direct access to said service capability servers (4,5) but allows a 

untrusted application (12) only access to proxy service capabiUty servers (9) running on 
the gateway node (1). 



4. A gateway node (1) according to claim 3, wherein said framework (15) initiates 
20 downloading of application program interface ftmctionality from said service capability 

servers (3, 4, 5) to said gateway node (1) forming said proxy service capability servers 
(9). 

5. Method for implementing a gateway node (1) as defined in claim 1, comprising 
25 the steps of: 

(a) receiving a request from an appUcation (10, 12) to access a 
service capability server (4, 5) external to said gateway node (1), 

characterised in that the method also comprises the steps of; 

(b) downloading of application program interface ftmctionality from said 
30 service capability servers (4, 5) to the gateway node (1) forming proxy 

service capability servers (9); 

(c) classifying the apphcation into either a trusted or an untrusted application; 
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(d) requesting said external service capability server (4, 5) to create an object 
instance implementing required application program interface functionality; 

(e) sending (21) a reference (22) to said object instance to said application if it 
is a trusted application (10); 

(f) sending (25) a reference (26) to said proxy service capability servers (9) to 
said application if it is an untrusted application (12); 

(g) operating said proxy service capability servers (9) to enable controlled 
communications between said imtrusted application (12) and said service 
capability server (4, 5). 

6. Method for implementing a gateway node (1), according to claim 5, whereia said ^ 
proxy service capability servers (9) are formed on said gateway node (1) every time 
said one or more applications (10, 12; 82) need access to said service capability servers 
(4,5). 

7. Method for implementing a gateway node (1), accordiiig to claim 5, wherein said 
proxy service capability servers (9) are formed on said gateway node (1) during an 
installation tinie of said gateway node (1). 



20 
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AMEPTOED CLAIMS 

[received by the International Bureau on 13 December 2002 (13.12.02); 
original claims 3 and 5 amended; remaining claims imchanged (2 pages)] 

1 . A gateway node (1) for implementing a gateway in an open service access 
network between one or more applications (1 0, 12; 82) and one or more external 

5 service capability servers (4, 5) on service capability server nodes (2, 3), comprising a 
ja-amework(15), 

characterised in that said framework (15) performs security checks on requests from 
applications (10, 12) to get access to one or more of the external service capability 
servers (4, 5) using service level agreements, stored in a database (28). 

10 

2. A gateway node (1) according to claim 1, wherein said fi-amework (15) classifies 
the applications (10, 12) in trusted and untrusted applications. 

3. A gateway node (1) according to claim 2, wherein said framework (15) allows a 
15 trusted application direct access to said external service capability servers (4, 5) but 

allows a untrusted application (12) only access to proxy service capability servers (9) 
Fanning on the gateway node (1). 

4. A gateway node (1) according to claim 3, wherein said framework (15) initiates 
20 downloading of application program interface ftmctionality from said service capability 

servers (3, 4, 5) to said gateway node (1) forming said proxy service capabiUty servers 
(9). 

5. Method for implementiag a gateway node (1) as dejSned in claim 1, comprising 
25 the steps of: 

(a) receiving requests from an application (10, 12; 82) to access one or more 
service capability servers (4, 5) external to said gateway node (1), 

characterised in that the method also comprises the steps of: 

(b) performing security checks on said requests using service level agreements, 
30 stored in a database (28); 

(c) downloading of application program interface ftmctionality from said service 
capability servers (4, 5) to the gateway node (1) forming proxy service 
capability servers (9); 

AMENDED SHEET (ARTICLE 19) 
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(d) classifying the application into either a trusted or an untrusted application; 

(e) requesting said external service capability server (4, 5) to create an object 
instance implementing reqnired application program interface functionality; 

(f) sending (21) a reference (22) to said object instance to said application if it is 
5 a trusted application (1 0); 

(g) sending (25) a reference (26) to said proxy service capability servers (9) to 
said appHcation if it is an nntrusted application (12); 

(h) operating said proxy service capability servers (9) to enable controlled 
communications between said imtrusted application (12) and said service 

10 capability server (4, 5). 

6. Method for implementing a gateway node (1)^ according to claim 5, wherein said 
proxy service capabihty servers (9) are formed on said gateway node (1) every time 
said one or more applications (10, 12; 82) need access to said service capability servers 

15 (4,5). 

7. Method for implementing a gateway node (1), according to claim 5, wherem said 
proxy service capability servers (9) are formed on said gateway node (1) during an 
installation time of said gateway node (1). 

20 
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